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Chess Computer 
using the Flash Micro Board 


presenting Deep Evelyn, 


the winner of the Flash Micro Board competition 


by P Azad and T. Gockel 


While the subject of chess using large computers can be dealt with in 
short order (the computer always wins), this project is intended to 
rekindle interest in user-programmed computer chess by making the task 
more challenging. The result is a chess computer based on the Elektor 
Electronics Flash Micro Board described in the December 2001 issue. 





People have been fascinated by machines 
and computers that can play chess since the 
time of Maezel’s chess robots. Many people 
have already attempted to create something 
that exceeds their own capabilities, occa- 
sionally venturing down very interesting 
paths in the process. For instance, just before 
the first computer came into existence, the 
mathematician Alan Turing developed a 
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chess program on index cards — and 
‘ran’ this program using himself as 
the processor. 

Nowadays, you might think that 
there’s not much more to be said 
about computer chess, since hardly 
anyone can beat the computer. How- 
ever, with the Deep Evelyn project 
we want to rekindle interest in user- 


programmed computer chess by 
making the task a bit more challeng- 
ing: computer chess using an 8-bit 
Atmel Flash microcontroller with 8 or 
12 kB of memory, programmed in C! 


Software 


Once we had the idea of implement- 
ing a chess program using the Atmel 
microcontroller, we quickly found 
basic C software for the move gen- 
erator, position evaluator and recur- 
sion (alpha/beta method) on the 
Internet. However, tests using vari- 
ous C compilers (Rigel and Wicken- 
hüser) failed, since the compilers 
could not handle the (already 
stripped-down) syntax, stumbled 
over the recursion or produced 
excessively large compiled code. The 
‘sdcc’ open-source compiler, to be 
described in a future issue of Elektor 
Electronics, ultimately appeared to 
be the most suitable. What remained 
was to modify the existing source 
code to meet our needs. This 
required the following changes: 

— dispensing with standard 
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Code Segment | 


// old... 
void foo() 
{ 
char i; 
for (i = 0; i < 8; i++) 
{ 
// common ... 
} 
for (i = 0; i < 4; i++) 
{ 
// common ... 
// extra... 
} 
} 
libraries 
— reducing the size of the compiled 
code 


— adapting the program to the 
Atmel memory model 
— optimising execution speed 


In order to dispense with standard 
libraries, it was first necessary to 
remove all #include instructions 
and replace the missing commands 
with our own code. We removed all 
I/O instructions and added suitable 
comments at the affected locations 
to facilitate inserting new I/O rou- 
tines. 

The first compilation using sdcc 
produced slightly more than 16 kB of 
code. Considering the amount of I/O 
code still to be implemented, this 
had to be reduced by at least 9 kB. 
Rather than giving up the spot, we 
scaled down our objectives. As 
described below under ‘Hardware’, 
the pin-compatible AT89S53 has 
more Flash memory (12 kB of 
instead of 8 kB), so in the worst case 
a 5 kB reduction would be just 
enough. 

To reduce the amount of compiled 
code, the source code was modified 
as follows: 

— stripping out constants 

— factoring out similar code 

— replacing the int data type with 
byte (char) where possible 


Stripping out constants is relatively 
easy. If a particular value is com- 
puted several times within a func- 
tion, it only has to be computed once 
and assigned to a variable, which is 


2/2003 Elektor Electronics 


// new... 
void help(char n) 


char i; 
for (i = 0; i < n; i++) 
{ 


// common ... 


if (n == 4) { // extra... } 
} 
} 


void foo() 


help(8); 
help(4); 
} 


then used instead of recomputing 
the value. This not only reduces the 
amount of compiled code, it also 
increases efficiency. However, it is 
easy to introduce errors by removing 
presumed constants that are actually 
not constants. All such changes 
must be carefully considered and 
checked by running the program. 

Factoring out similar code is sig- 
nificantly more complicated. Except 
from the trivial case of identical 
blocks of source code, it requires 
intuition and creativity. If two pieces 
of code appear to be similar, they 
can often be combined into a single 
function, for instance by introducing 
additional variables and IF queries 
(see Code Segment 1). 

Such changes, if made in a rea- 
sonable manner, yield a significant 
reduction in the amount of compiled 
code, but they increase execution 
time. Just calling a function twice 
costs time, due to the implicitly exe- 
cuted push and pop operations for 
the return address, possible para- 
meters and context saving. Addi- 
tional code for differentiating the var- 
ious tasks, such as IF queries, adds 
to this. 

Replacing the int data type with 
char (if possible) yields a fundamen- 
tal improvement in code size, mem- 
ory usage and execution time. The 
sdcc compiler interprets char as an 
8-bit data type and int as a 16-bit 
data type. Since the AT89S53 has an 
8-bit ALU, an operation such as mul- 
tiplying two int variables is split 
into several 8-bit multiplications and 
additions. 


It is generally not possible to simply 
change int to char, since this can lead to a 
considerable loss of information (65,636 vs. 
256 values). However, it was possible to 
replace all instances of int by char except 
for the evaluation function. Originally, the 
#define statements for the various chess 
pieces were used for both differentiation and 
evaluation. By splitting the IDs and values of 
the individual pieces into separate #define 
statements, it was possible to reduce the 
playing-field array to the char data type, 
allowing all routines except the evaluation 
function to use significantly less costly 8-bit 
operations. 

Adaptation to the Atmel memory model 
was necessary because the Atmel microcon- 
troller has only 256 bytes of internal RAM. 
First, all global variables (primarily the arrays 
for the playing field, moves etc.) were moved 
to the 32-KB external memory by putting the 
keyword xdata in front of the declarations. 

Once we had gotten this far, we could let 
the chess computer play against itself and 
follow the moves using the serial interface. 
The first move was ‘a8aQ’ (!), which led to a 
tedious debugging session. After we finally 
cut back the complete chess program to 
around five lines that simply filled an array 
using a FOR loop and read it out again, and 
found that this simple program did not work 
properly, it was clear that there was some- 
thing wrong with the sdcc compiler. Totally 
discouraged, we disabled all compiler opti- 
misation — and were rewarded with success! 

After this, our chess computer gave ‘a2a3’ 
as the first move, which at least showed a 
certain similarity to ‘e2e3’, the move speci- 
fied by the same program running under Win- 
dows... 

Although the 256 bytes of internal RAM 
should have been more than adequate for the 
remaining local variables and the stack, it 
turned out that practically all variables not 
marked with xdata are potential sources of 
errors. At this point, we had enough experi- 
ence to not worry about why or try to sys- 
tematically nail down the cause of the prob- 
lem. Instead, we adopted the drastic solution 
of entirely avoiding the use of internal memory. 
In particular, this meant: 

— replacing function parameters with global 
variables 

— replacing local variables with global vari- 
ables 

— implementing our own runtime stack 


The alpha/beta function is the only recursive 
function in the chess program. This means 
that all of its parameters, local variables and 
return address are implicitly placed on the 
runtime stack each time it is called, so they 
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Code Segment 2 


// old... 


int value; 
int foo(char a) 
{ 
char local; 
if (a == 5) 
return a; 
// codel ... 
value = foo(a + 1); 
// code? ... 
return value; 


} 
// new 


xdata int value; 

// for current stack content 

xdata char a; 

xdata int local; 

xdata char ret; 

// corresponds to return value register 

xdata char retval; 

int foo() 

{ 

begin: 
// fetch parameters and return address 
a = stack[stackp].a; 


ret = stack[stackp].ret; 
if (a == 5) 
{ 

retval = a; 

if (ret) 

goto ret; 

return; 
} 
// codel ... 
// update stack contents (save context) 
stack[stackp].a = a; 
stack[stackp].local = local; 
// push (parameters & return address) 
stack[++stackp].a = a+ l; 
stack[stackp].ret = |; 
goto begin; 


ret: 


// pop (restore context) 
a = stack[—stackp].a; 
local = stack[stackp].local; 
ret = stack[stackp].ret; 
// fetch return value 
value = retval; 
// code? ... 
retval = value; 
if (ret) 

goto ret; 
return retval; 


can be read out and removed from the stack 
each time it executes a return. All of this, 
which is normally handled by the program- 
ming language, now had to be explicitly pro- 
grammed. 

A sruct array encompassing all of the 
above-mentioned variables is used for the 
stack. Since labels are not types in C and thus 
cannot be assigned to variables, return 
addresses must be implemented indirectly 
using IDs and IF queries. It would have been 
conceivable, and certainly somewhat more 
efficient, to use an inline assembly-language 
solution. Code Segment 2 shows an example 
of the modified code. 

With regard to optimising execution 
speed, the colours of the pieces are distin- 
guished in the chess program by the sign of 


the ID: a positive ID describes a 
white piece, while a negative ID 
describes a black piece. The effi- 
ciency of the evaluation was 
improved by a factor of around 2 by 
using two separate branches in the 
evaluation algorithm to differentiate 
between the white and black pieces, 
instead of handling the difference by 
repeatedly multiplying by a variable 
(1 or -1) in a single block of code. 
This allowed so many multiplica- 
tions to be eliminated that the com- 
piled code was smaller, even though 
the number of lines of source code 
was nearly doubled. 

It also proved to be very practical 
to use #define and dummy #define 


Operating Instructions 


Enter a move when prompted to do so. 


For example, to enter e2e4, press the E/, /2, E/ and /4 buttons in sequence. 
To correct a false entry or delete a complete line, press ESC. 
To confirm or transmit your entry, press RETURN or <-, respectively. 
Short castling: press the # button (now labelled /r). 


Long castling: press the /I button (now labelled /R). 


To select the computer’s move (microcontroller computes the next move): press 


RETURN or <- without entering a move. 


New game: press the Reset button on the Flash Board. 
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statements (#ifdef WIN32 
#enddef) to allow the source code 
to be compiled as a console program 
running under Windows, so basic 
program operation could be checked 
and/or debugging could be conve- 
niently performed in a Windows 
environment. 

In addition, output via the serial 
interface was a great help in the 
development phase. The necessary 
routines can easily be taken from a 
small demo program (hi.c) pro- 
vided with the sdcc compiler. An 
even more convenient solution 
would be to use the freeware pro- 
gram PaulMon2, but we were not 
able to test this in the short amount 
of time available (ten rather long 
evenings). 


Hardware 


For this project, we concentrated on 
the software and intentionally 
avoided fancy inputs and outputs. 
Nevertheless, we made a few small 
changes to the hardware of the 
Atmel AT8988252 Flash Micro Board 
as described in the December 2001 
Issue of Elektor Electronics. 

The voltage regulator was 
replaced by an equivalent low-drop 
type (such as an LT1086CT-5, which 
however has a different pin arrange- 
ment (gnd/in/out instead of 
in/gnd/out), or an LM2940 or equiva- 
lent) and the input voltage was 
reduced, since the original 7805 
became much too hot with the LCD 
background illumination switched on 
(with a 10Q series resistor), due to its 
high drop-out voltage (around 3 V). 

User input is via a keypad com- 
posed of 12 digital pushbutton 
switches fitted in the prototyping 
area. Since each switch is wired to 
ground, 12 port pins are required. 
There was no need to economise on 
port pins by using a matrix connec- 
tion. The assignment of port pins to 
switches can be easily seen in func- 
tion AskPlayerMove() in the 
source code (userinit.c). The 
switches are debounced by a simple 
delay (50 ms, which can be changed 
as desired). The button arrangement 
matches a telephone keypad, and 
the button functions and operation 
are practically self-explanatory (see 
the Operating Instructions box). 
Note that the program does not 
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check entered moves for correctness, 
so if you want to cheat (yourself) you 
are free to do so. 

The 16 x 2 LCD is connected to 
the address/data bus. It can be 
addressed in the syntax of the 
selected C compiler (sdcc) using the 
xdata (external RAM access) com- 
mand. An example of such an 
access is: 


volatile xdata unsigned char 
at 0x8000 cmd_write; 


The board presently holds an Atmel 
Atmel AT89S53-24PC, which is pin- 
compatible with the AT895252 but 
has 12 kB of Flash program memory 
instead of 8 kB (but no EEPROM). 
However, with the stripped-down 
user interface, the program would 
probably also run in the AT898252. 
The actual amount of program mem- 
ory required by the compiled code 
can be seen under CSEG in the .map 
file generated by the compiler. 
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Results and prospects 


The current version of Evelyn is a 
chess computer that cannot compete 
with professional devices or PC pro- 
grams, although it can beat an ama- 
teur. However, the purpose of this 
project was not to create a high-per- 
formance chess computer, but rather 
to show how a relatively complex C 
program can be transferred from a 
PC environment to a much less pow- 
erful microcontroller environment. 
The references provide further infor- 
mation that you might find useful in 
your own projects. 

One last thing: the name of the 
chess computer was inspired by the 
following highly informative sdcc 
compiler message: 


Warning: conditional flow 
changed by optimiser 
‘chess.c(386)’: so said 
EVELYN the modified DOG. 
(031001-1) 


For further information: 


www.artilect.co.uk/lego/ 
default.asp?page= Chess 


‘The Chess Robot Project’: 
chess on Lego Mindstorm (download) 





http://sdcc.sourceforge.net 
Home page of sdcc (small-device C com- 
piler): documentation and download 





www.turbobit.com/mem5 |. html 
Information about the memory mapping of 
8051 derivatives with reference to the sdcc 
.map file 





www.geocrawler.com/archives/3/3278/2000 
sdcc user forum 





www.estpak.ee/~nq002a/liter/picapps.pdf 
‘Interfacing a Matrix Keypad’ and other PIC 
applications 





www.pedram-azad.de 

Download URL for the latest version of the 
chess computer program and related docu- 
mentation 
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